1. Field of the Invention
Embodiments of the present invention relate generally to performing computations on a graphics processing unit and more specifically to a method for performing undo and redo operations on a graphics processing unit.
2. Description of the Related Art
Software graphics applications commonly include a user interface that allows a user to perform selected operations on graphics objects managed by the software graphics application. One example of a software graphics application is a drawing program, which allows a user to create and modify graphics objects using one or more drawing tools provided by the drawing program. In a typical usage scenario, the user creates an image by invoking various drawing tools, such as a paintbrush, a pencil, and an eraser, each with an associated action. Each action performed by a drawing tool may modify the image and the underlying application data that represents the image. For example, the user may add a brush stroke to the image using a paintbrush tool, which modifies the application data to add the brush stroke. Oftentimes, the user may wish to discard one or more previously performed actions to, for example, undo mistakes or to aesthetically improve on previously performed actions. To facilitate discarding previously performed actions, software graphics applications conventionally provide an undo operation that allows the user to undo one or more actions. A related redo operation allows the user to re-perform an action discarded using the undo operation.
An undo operation may be conventionally performed by copying and maintaining sequential versions of application data in response to actions that modify the current application data. In some implementations of an undo operation, a complete copy of each version of the application data may be instantiated to accommodate each action, thereby enabling a corresponding undo operation. For example, a drawing program may maintain sequential copies of an entire image being modified by the user in a given action. However, instantiating a complete copy of the application data can be quite time consuming and may require a significant amount of memory. A more efficient implementation instantiates only the portion of the application data that is actually modified in a given action. For example, the drawing program may divide the image into tiles and only save modified copies of those tiles modified by the action. Each sequential version of the application data is represented by a set of references to the tiles. When a given tile is modified, only the data for that tile needs to be copied and modified, and the reference to the tile is set to refer to the modified tile. This technique may treat each tile as a reference-counted object, using a set of reference counters to facilitate the copy on write mechanism.
Certain software graphics applications are structured to partition computational work over multiple threads, where some threads execute on a central processing unit (CPU) and other threads execute on a graphics processing unit (GPU). One common structure of a software graphics application, referred to herein as a “GPU enabled application,” incorporates CPU threads configured to implement a user interface as well as perform overall application management, and GPU threads configured to perform graphics operations under the control of the CPU threads. Inter process communication between a CPU thread and a GPU thread is typically performed via a system interconnect, such as the industry standard PCI-express. For the software graphics application to fully accommodate undo operations, multiple versions of the application data need to be kept, including data generated by the GPU threads. However, GPUs conventionally do not provide sufficient flexibility to implement sophisticated data management techniques, such as copy on write, which may be used to increase the efficiency and performance of undo and redo operations. Furthermore, GPU systems typically do not include sufficient extra memory resources to allow complete instantiation of multiple versions of application data stored within local GPU memory. Storing versions of application data generated by the GPU in system memory is problematic because the system interconnect bridging the GPU to system memory typically becomes or aggravates a performance bottleneck, which diminishes overall system performance. In each scenario, conventional techniques for facilitating undo operations on data generated by the GPU are limited by the limited resources and flexibility of the GPU.
As the foregoing illustrates, what is needed in the art is a technique for efficiently facilitating undo operations in GPU enabled applications.